IBIS Macromodel Task Group Meeting date: 09 June 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Bob to send BIRD201.1_draft8 to the ATM email reflector and for submission to the Open Forum. - Done. - Randy to post BIRD201.1 on the IBIS Open Forum BIRDs web page. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 02 meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: Editorial Change to Rx_Clock_Recovery_Mean: Hansel shared a slide detailing his proposed change. He noted that he found the language: "... medians of consecutive edge transition times ..." in the Definition of the parameter to be confusing. He said "transition times" led him to think of the time it takes to transition from one state to the other. He proposed changing the text to: "... medians of consecutive edge threshold crossing times ..." Similarly, he proposed changing "edge transition times" to "edge threshold crossing times". No one expressed opposition to the proposal. Arpad asked if it would be handled as an editorial process or required a BIRD. Bob, Randy, and Radek said that it should be handled as a BIRD because it is more of a clarification of a technical point than a pure editorial change. Hansel took an AR to draft a BIRD. Supporting PI Simulation in IBIS: Zhiping noted that he had given a presentation about the topic at the last Open Forum meeting. He said people had pointed out that IBIS is primarily focused on I/O. He agreed, but said that PI and SI are often closely coupled for I/O, and PI can affect core and I/O. He noted that some IBIS keywords, e.g., [ISSO_PU] and [Composite Current], were designed around PI. He said that system designers typically want to include PDN modeling and often resort to ideal power management IC models. However, they really want to simulate SSO noise and timing jitter, and it would be more accurate to have PMIC behavior modeled in the simulation as well. Arpad said that many EDA tools are now offering power-aware simulations with the power delivery network included. He asked if Zhiping had a vision for the simulation flow. He said part of the difficulty was the widely differing frequency ranges to be simulated for I/O buffers and VRMs. A related issue was the on-die and on-board decoupling capacitance question. At the higher speeds of I/O buffers, package and even on-die decoupling caps are more important. Zhiping agreed that most people are interested in the GHz range for I/O. However, he said that even for a GHz link the jitter spectrum is much lower. Typically CDR jitter tracking is in the MHz range. He said that in the past people typically tried to run SI and PI simulations independently and then estimate their coupled effects. But nowadays most accurate simulations need SI PI cosimulation. For example, for a SOC DDR bus, you have signal and power closely coupled in a thick package. It would be inefficient and or inaccurate to try to model SI and PI separately. Jitter is another area where cosimulation is important. In a SERDES you have a clock tree, CDR, etc., and you're worried about power supply induced jitter (PSIJ), so people want to run the jitter simulation in conjunction with the power simulation. Arpad asked if Zhiping had any ideas for the type of information we could add to an IBIS model to help. He again noted the widely varying timescales and said that if you're simulating GHz I/O buffers (ps time scales), but you need to run long enough for a VRM with a feedback loop in the 100kHz range, it will take forever. Zhiping said he didn't have an answer or a solution. He was hoping we could all agree that PI simulation is an important problem for high speed IC design. He noted that the IEEE EMC Society is holding a sandpit event to collect industry feedback and categorize it into different buckets. He suggested, for example, that it might be easy to come up with an IBIS keyword to add to support DC analysis and describe power dissipation. For AC or transient analysis, however, solutions could be more complicated and controversial. He was hoping IBIS could help find a way to standardize the necessary information in much the same way it had for I/O modeling. Walter asked if, from the point of view of IBIS I/O buffer models, all we needed to do was add a keyword indicating the number of Coulombs (amount of charge) the buffer uses for each transition. With that data, EDA tools could look at the duty cycle of the I/O signal and other factors and compute the spectral density of the power consumption and how the voltage rails would vary. Walter said you could integrate over a [Composite Current] curve, which contains current vs. time. Zhiping said coming up with a single number for Coulombs per transition would be tricky, since it varies with many factors. The [Composite Current] BIRD itself envisioned tables for 3 sets of load conditions. Walter then said you could then run a single IBIS simulation given the channel being driven, and it would determine the Coulombs per cycle consumed. This was all IBIS would need to contribute to a low speed PI simulation. Zhiping said I vs. time provides more information than total charge consumed, and it's a question of how fast you need the charge delivered through the PDN that is important. Walter agreed that would be a more interesting simulation, but it was outside the domain of IBIS I/O simulation. Arpad asked for feedback from IC vendors. Walter noted that every time he'd worked on this with IC vendors in the past, either using measurement or sophisticated simulation, they would find a spectral density of the rail voltage and that would be their power aware simulation. The IC vendors would do that simulation, not their customers, and they would use that simulation to compute jitter parameters to put in their models. Arpad asked what the main purpose of this would be, modeling the VRM? Zhiping said he was thinking of two parts, first how to model the VRM, and second how to model the sink . For the sink modeling, you could have I vs. t, or average power, or peak, and possibly DC and perhaps including noise specifications and requirements for the power rail. Arpad suggested we move on to other topics and return to this one next week. Zhiping asked everyone to feel free to send him questions and feedback via email. He noted the upcoming IEEE EMC Society sandpit event and said he'd be happy to include anyone in those discussions. BIRD201.1 demo: As he'd agreed to do at the previous meeting, Walter provided a demo of his BIRD201 type proof of concept simulation. His demo was for a DDR5 channel in which the Tx had a 3-tap FFE and the Rx had a 4-tap DFE, i.e., a typical DDR5 write simulation. He showed a MATLAB implementation of the flow. The script took in the step response(s) (rising, falling or both) of the channel, generated the IR, and called the Tx and Rx AMI_Init functions repeatedly (calling AMI_Close after each call to AMI_Init). It implemented a simple steepest-descent algorithm. For each step in the optimization, 15 simulations were run: one at the current tap settings, and one simulation for each of the taps with its value raised by one, and one simulation for each of the taps with its value lowered by one. Whichever simulation yielded the best metric was the one chosen for the next step. In the DDR5 example it took about 165 iterations to converge and about five seconds. In a more complicated 23 tap FFE example it had taken about 1000 iterations, but was still fast enough. The script computed metrics like eye height, eye width, COM, area, width times height. Walter noted that in a true BCI Statistical BIRD201.1 flow, instead of the logic being in the script (EDA tool), it would reside in the Tx or Rx AMI_Impulse function. In a DDR5 write scenario, it would reside in the Tx AMI_Impulse function, since the controller optimizes the channel on writes. Walter noted this his script generated COM and eye height at two locations, one where the maximum eye height occurs, and one at the midpoint of the eye with respect to the left and right crossings. He noted that the newly introduced BIRD205 lets the model determine where the sampling location should be, which also affects the DFE since it kicks in 0.5*UI later. It's also why the clock forwarding BIRD204 was introduced, because when the DQS crosses zero is when you typically sample the DQ. Fangyi asked about the COM values displayed by Walter's script, and noted that COM has its own CTLE, DFE, etc. Walter agreed, and said that COM essentially says, "give me an IR, and I have my own DFE, FFE and CTLE", and it doesn't generate an eye it generates a single histogram at a particular sampling time. The COM value is the signal to noise ratio. Walter said his script computed the SNR with the signal being the inside height of the eye. He said COM typically just assumes you can equalize the channel properly in your implementation. For example, it zeros out the pulse response for as many taps as you have, and then computes SNR. It doesn't really care about the details of any particular implementation, it just assumes the implementation can handle the equalization correctly. It's purely a metric of the channel. - Curtis: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. AR: Hansel to draft a BIRD for his proposed change to the text defining Rx_Clock_Recovery_Mean. ------------- Next meeting: 16 June 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives